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1. Abstract 


The European research and development community, as represented by 
the member research networks of RARE, has lead the deployment within 
the global R&D community of X.400 electronic messaging services, as 
specified in the international recommendations CCITT X.400(1984), for 
more than five years. As a result of providing such services to the 
European R&D users it has become clear that there is an existing and 
ever increasing demand from these users for new and enhanced 
electronic messaging services and product to be used to communicate 
within the R&D community but within commercial service providers and 
organisations as well. 


It is also clear that new services, such as Multimedia messaging and 
Secure messaging, and the resulting products promise dramatic 
benefits and opportunities, for not only the R&D community but also 
for the wider commercial, industrial and public communities, in terms 
of facilitating innovative ways of working and living which can only 
enhance the missions and goals of the respective communities. Not 
least the establishment of globally pervasive messaging services 
between all users, R&D and commercial, is facilitated by the early 
adoption of such advanced new services. An indication of the 
importance of such a messaging service can be appreciated if one 
considers that in many organizations (especially commercially based) 
messaging may be the only method to communicate between independent 
organizations due to security considerations and lower layer network 
differences. 


The Commission of European Communities (CEC) VALUE subprogram II has 
been established to support initiatives relating to the development 
and adaptation of R&D networks in member states. Amongst other 
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initiatives the VALUE program supports X.400 initiatives in certain 
countries. VALUE support has so far been limited to X.400(1984) 
initiatives, as X.400(1984) has up until now been the dominating OSI 
services. However as X.400(1988) implementations have started to 
appear a VALUE funded study of the X.400(1988) aspects of messaging 
and their impact on the R&D community was felt necessary. This report 
is one of the results of that study. 


The report documents the results of a task force on X.400 (1988) 
deployment of the RARE Mails and Messaging Work Group during the 
period from November 1992 until October 1993. Open reviews of the 
report have occurred in the RARE Mail and Messaging Work Group and 
within the IETF X.4000ps Working Group. 


The scope of the report is limited to deployment of X.400 (1988) 
services, and as such the report does not contain any recommendations 
on development and deployment of Internet RFC 822 / MIME/ PEM related 
(pilot) services. However, since the report shows that both 
X.400(1988) and RFC 822 / MIME / PEM will be developed and used 
within the European R&D community, such a pilot should also 
considered. Note: RFC 822 is also known as Internet STD 11. 


Circulation of this report is unlimited. Comments on this report may 
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2. Management Summary 


This document reports the results of study of the X.400(1988) aspects 
of messaging and their impact on the R&D community. The study was 
funded by the CEC under VALUE Subprogram II and has been carried out 
by a task force on the RARE Mail Working Group. The document is 
targeted at technical decision makers as well as those who would fund 
activity in this area. 


The document presents the existing situation as regards the 
predominate messaging technologies within Europe. These are presented 
within the context of a number of large messaging communities that 
are using these technologies: 


RFC 822, 

X.400 (1984), 
Mail-11 and 

PC LAN messaging 
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Three major European communities are referenced: 


- Commercial service providers 
—- R&D community 
- Commercial organisations using messaging services. 


The report states the following facts: 


-— The resources, human or financial, to operate multiple wide 
area messaging services connecting together independent 
organisations are high. As such it is desirable to try and 
keep to a minimum the number of such services. This statement 
is true for the R&D community but is also highly likely to be 
valid for the general European industry. 


—- There are two publicly available technological standards 
that can be used by open communities, such as the R&D 
community and public service providers: the X.400(1984 and 
1988) recommendations and the Internet RFC 822 / MIME / PEM 
standards. 


-— There is an established very large global user base of 
Internet RFC 822 and X.400(1984) messaging services. Both 
services have their own momentum within different parts of 
the user community, both are still developing and growing 
fast. 


The report concludes that X.400(1988) will be the preferred protocol 
for inter organizational connection for European industry and 
government and parts of the European R&D community. RFC 822 / MIME / 
PEM will be the preferred protocol suite for inter-organisational 
connection for the Internet community and, as products are already 
widely available, it is the preferred protocol for parts of the 
European R&D community. 


The goal of European pervasive messaging - incorporating Industry, 
Government and Academia - would be best accommodated and reached by 
the establishment of a single messaging service. However taking the 
above into account, this is not feasible, as X.400(84 and 88) and RFC 
822( and MIME) based services will be around for a long time to come. 
To increase the functionality of Wide Area E-mail services there is a 
clear necessity to: 


- migrate RFC 822 services to a RFC 822 / MIME / PEM service. 
A MIME based service offers more functionality to the user 


than a plain RFC 822 service. 


- migrate existing X.400 services to a X.400(1988) service. 
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Due to the lack of scalability of the X.400(1984) service in 
terms of extra functionality, it will become increasingly 
difficult to meet the needs of research users of existing 
X.400(1984) services unless an X.400(1988) service is put 
into place. 


— provide a transparent gateway between X.400 (1988) and RFC 
822/MIME/PEM. For the European R&D community it is essential 
to have a transparent gateway between the X.400(1988) service 
and the RFC 822 / MIME / PEM service, thus ensuring 
connectivity between these two services with a maximum 
functionality. 


Such a gateway is technically feasible and it is an essential part of 
an unified E-mail service. Without such a standardised gateway the 
overall E-mail service would deteriorate. 


The lack of open standards for the PC LAN messaging systems 
discourages their use as ’backbone’ messaging technologies within 
open communities. However the products that these systems deliver to 
end users ensures that their already large share of the messaging 
market will continue to exist for some time. Thus it is also 
essential that strategies that allow these systems to be ’seamlessly’ 
integrated within the global messaging community are put in place. 
Not least due to the indications that the main messaging vendors are 
developing X.400(1988) and RFC 822/MIME gateways, a strategy to link 
these systems together via X.400 and RFC 822 should be developed. 


The report concludes with a set of recommendations, the main one 
being the establishment of a X.400(1988) European pilot messaging 
service for the R&D community. This pilot should include the 
establishment of a transparent gateway service between X.400 (1988) 
and RFC 822/MIME. The goal of a European pilot is to ensure the 
successful deployment of a European wide operational X.400 (1988) 
service that is pervasive and meets the needs of users. By collecting 
together the issues related to the establishment of a European 
X.400(1988) service, this report acts as a focal point and stimulant 
for discussion on this topic within the R&D community. In the report 
a summary of the benefits and problems of each of the above messaging 
technologies within the context of achieving a global messaging 
service, of which the R&D community is one part, is presented. 
Further the document identifies issues, strategies and 
recommendations related to the migration and coexistence of these 
technologies within the scope of mainly the European R&D community 
but also in relation to other messaging communities. A cost / benefit 
analysis on the establishment of a European wide pilot X.400 (1988) 
messaging service is also presented. Finally a reading list of 
references related to this subject has been compiled. 
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The report does not include any recommendations on development and 
deployment of RFC 822 / MIME / PEM related (pilot) services, as these 
are outside of the scope of the Task Force. However, since the report 
shows that both X.400(1988) and RFC 822 / MIME / PEM will be 
developed and used within the European R&D community, such a pilot 
should also be considered. 


3. Framework for the report 


With the belief that user demands for new messaging services such as 
Multimedia and Secure Messaging would develop, the RARE community 
(together with other communities; most notably the Internet 
Engineering Task Force (IETF)) has over the preceding years 
experimented in new messaging and related technologies. Experiments 
and pilots, have been performed in messaging services e.g., as 
recommended by CCITT X.400(1988) and Directory Services based upon 
the CCITT X.500(1988) recommendations. 


The results of such pilots and experiments indicate that it is now 
opportune to commence a pilot X.400(1988) messaging service for the 
European R&D community. The major goals of the pilot being, to 


- establish a large scale European wide pilot messaging 
service based on X.400(1988). 


- collaborate with and facilitate the commencement of similar 
pilot services within diverse communities; both R&D and non- 
R&D (e.g., commercial ADMDs and PRMDs, etc.); both European 
and non-European (e.g., North American , Asian, etc.). 


— encourage and assist the development and deployment of a 
wide variety of commercial and public domain X.400(1988) 
messaging products that meet the user’s needs, for instance 
X.400(1988) products such as User Agents (UAS), Message 
Stores (MSs), Message Transfer Agents (MTAs) and gateways 
between X.400(1988) services and other widespread messaging 
services i.e., RFC 822, Mail-1l1 and proprietary. 


— prove that such a service and products efficiently meets the 
existing and expected demands for new messaging services by 
European R&D users. And as such determine the steps for a 
European deployment of an operational X.400(1988) messaging 
service. 


- determine the needed steps to facilitate migration for the 
existing operational R&D X.400(1984) based messaging service, 
as represented by the R&D MHS service (the former COSINE 
MHS), RFC 822 / MIME / PEM based messaging services and the 
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HEPnet / SPAN Mail-11 based messaging service to an 
operational X.400(1988) messaging service. It is self evident 
that during such migrations, transition steps must be 
included that allow a period of coexistence, at the highest 
possible service level, between X.400(1988), X.400(1984), RFC 
822 / MIME and HEPnet / SPAN Mail-11 services. 


- determine the needed steps that allow proprietary messaging 
systems, that are widely deployed within the European R&D 
community to be integrated at as high as possible service 
level, by an X.400(1988) infrastructure. 


This report identifies the issues involved in such a pilot service. 
It is not a concrete proposal for such a project but the report 
discusses advantages and disadvantages, costs and enefits and 
migration issues for deploying a X.400(1988) service. As such it is a 
discussion and feasibility paper on the creation of a large scale 
European wide pilot X.400(1988) messaging service for the European 
R&D community. 


4. Present situation of European Messaging 
4.1. Messaging services 


Electronic messaging within Europe can be viewed as a number of 
messaging services communities. Three important communities comprise, 


—- Commercial e-mail networks, 
—- Research e-mail networks and 
- PC LAN messaging systems. 


Commercial e-mail networks are classified as either ADMDs or PRMDs. 
ADMDs and PRMDs are operating in nearly every European country. 


- ADMD services (or public commercial e-mail services) are 
provided by over 50 service providers which have 
interconnected using the X.400(1984) protocols. The topology 
between these ADMDs, although not yet ’mesh’, can be stated 
as progressing quite rapidly to this optimum goal. However 
there is still a way to go before ADMDs provide full European 
connectivity. 


- PRMDs (or private commercial e-mail service providers) have 
interconnected to ADMDs and other PRMDs predominantly using 
the X.400(1984) protocols but also with proprietary 
protocols. 
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Research networks are providing messaging services in every European 
country. These R&D service providers are operated as either ADMDs or 
PRMDs and are using both X.400(1984) protocols and Internet RFC 822 
protocols to connect to each other. 


Moreover, there are also large R&D communities (i.e., HEPnet and 
SPAN) using proprietary protocols (i.e., DECnet Phase IV and Mail-11) 
as their main messaging systems. The DECnet IV based communities are 
now migrating to DECnet Phase V (OSI connectionless protocol stack), 
which provides X.400(1988) (plus X.400(1984)) as a major messaging 
system. In general, all these services are totally interconnected. 
As such it is a statement of fact that there exists within the 
European R&D community, two parallel interconnected messaging 
infrastructures based upon X.400(1984) and RFC 822. However 
interconnections between the R&D messaging community and the majority 
of the European commercial service providers use the X.400 (1984) 
protocols. 


It is also clear that the commercial world mostly makes inter- 
organizational messaging interconnections using the X.400 (1984) 
protocols. And also that the commercial messaging world is not as 
totally interconnected as the R&D messaging community. Finally, for 
a number of commercial and public organisations there is often a 
mandatory requirement to use X.400 for messaging interconnections. 


The usage of PC LAN messaging systems is increasing very rapidly 
within the academic and commercial communities. In general, PC LAN 
messaging services within both communities do not use X.400(1984) or 
RFC 822 messaging systems but systems based upon proprietary 
protocols. The PC LAN messaging systems can be considered more as 
‘Islands of Messaging’ that gateway to the commercial and R&D 
messaging services by using X.400(1984) or RFC 822 gateways. PC LAN 
messaging systems within commercial organisations connect to 
commercial service providers also via proprietary protocols. The PC 
LAN messaging services, although probably comprising the largest 
number of users, are in general poorly integrated with the global 
messaging service (The Dutch, UK and Italian academic communities 
confirm that there appears to be many such ’Islands’ of PC LAN 
messaging systems within their networks.). 


4.2. Requirements for messaging 


Experience with existing global e-mail services has proven that with 
the increased use of messaging, there follows an awareness of extra 
requirements for related services. These requirements can be 
classified into ’User based Requirements’ and ’Service Provider based 
Requirements’ to either support, or exploit, high quality messaging 
services. These requirements are elaborated upon within this chapter. 
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4.2.1. User Oriented 


The only thing a user requires is an easy to use, well integrated, 
user interface to electronic mail. Usually the user does not care 
what protocol is used. However there are certain inherent 
requirements to the functionality that can be identified as user 
requirements. The main user requirements identified are: 


- Distribution Lists (DLs) 


A widely perceived omission from the X.400(1984) recommendations 
was the lack of support of DLs. Distribution lists allow users to 
enlist themselves onto electronic mail expander lists 
(distribution lists). A message to such a distribution list will 
automatically, and without significant delay, be sent on to anyone 
whose electronic mail address is on that list. Such a list can be 
a public list, that is meant for discussions on a specific 
subject, much like a sort of "magazine". However the list can also 
be a "closed" list, containing only a selected set of people who 
need to communicate privately, e.g., a project-—team. 


—- Multinational language and Multimedia support 


European users have for many years been frustrated in their 
inability to use their national character sets when communicating 
using messaging systems. The problems within e-mail systems that 
were causing this character set frustration are at their base the 
same problem that would get in the way of Multimedia messaging 
like: 


- lack of binary data support 
- lack of standardised encoding schema’s 
- definition of multiple body-parts 


The enormous potential of Multimedia systems and services 
(especially within the commercial community as evidenced by the 
enormous press publicity and mega-mergers positioning companies to 
exploit this technology but also within the government spheres 
i.e., the U.S.A. Government’s ‘Information Superhighway’ 
initiative) has acted as a spur to make rapid progress in solving 
the problems in this area. 


- White pages Directory Service 


A white pages directory service provides a unique but very basic 
and important service; a way to store and find information about 
people and resources that is analogous to a telephone service’s 

paper based directory i.e., White Pages. User’s E-mail addresses 


RARE WG-MSG Task Force 88 [Page 9] 


RFC 1616 X.400(88) for European Academics and Research May 1994 


can be stored for subsequent retrieval by E-mail systems. 
- EDI 


EDI today is not extensively used within the academic environment. 
However there is a distinct potential within the academic 
community to reduce costs and improve services with EDI. Potential 
EDI uses could be, 


- EDI between universities 

-— EDI between universities and government 

- EDI between universities and lower level educational 
institutions (e.g., student records) 

- Commercial EDI using the Internet as an infrastructure. 


The significance of maintaining end to end integrity (especially 
security aspects) of the EDI messages mandates that no gateways 
should be used between originator and recipient. 


-— Support of Security services 


E-mail as it is currently used is far from secure. To allow for 
serious usage of E-mail security issues need to be addressed, 
like: 


- integrity; making sure that the message is transferred 
intact, without any changes or additions. 

- encryption; making sure the message content is only 
decipherable by the intended recipient. 

- authentication; making sure that the originator and/or 
recipient are authenticated. 


4.2.2. Service provider viewpoint 


The task force believes the following points as being the most 
significant service provider requirements: 


- Network Management 


This area is still very new, in terms of offering standardised 
protocols, services and products for management. However a minimum 
‘goal’ is to provide for central management functions that will 
allow providers to offer a better quality of service. There is 
presently ongoing work within the IETF Working Group MADMAN to 
define SNMP monitoring and managing of E-mail systems, gateways 
and X.500 directory systems. A number of management areas that 
need to be worked upon include: QOS, Service Level Agreements 
(SLAs), Multiple system queue management, Accounting, Routing Co- 
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ordination and Message Tracing. 
— Support of MTA routing 


Dynamic routing from MTA to MTA, relieves the necessity to 
maintain large routing tables, especially within a large PRMD, or 
community of PRMDs (like the R&D MHS community). 


- Address mapping between RFC 822 and X.400 


The widespread use of X.500 or DNS for mapping, allows a reduction 
of manpower for centrally co-ordinating globally consistent 
X.400-to-RFC-822 mapping tables and distributes the responsibility 
for updating the mapping rules. This should allow mapping rules to 
change when needed and to be available immediately. 


- UA capabilities registration 


The use of the directory to register UA capabilities for 
X.400(1988), X.400(1984) and RFC 822 / MIME / PEM systems is a 
very desirable benefit for users in terms of speeding the 
deployment of new messaging services (e.g., Multimedia Messaging). 


4.3. Messaging capabilities 


Due to the problems of gatewaying within a multi-protocol messaging 
environment, the great majority of R&D E-mail users are reduced to 
using only InterPersonal Messaging (IPM) services based upon the 
exchange of message body parts using CCITT character set IA5 (US 
ASCII). 


Within the R&D community recent work to meet user requirements for 
non ASCII messaging services - as documented above - has resulted in 
enhancements to the messaging services based upon RFC 822 protocols. 
The enhancements provide Multimedia support via the Multipurpose 
Internet Mail Extensions (MIME) and the prospect in the very near 
future of secure messaging via Privacy Enhanced Mail (PEM). 
Deployment of the MIME enhanced RFC 822 based services, via 
distribution of software and the setting up of the needed 
organisational structures, has commenced. The PEM enhancements are in 
a large scale pilot phase e.g., VALUE PASSWORD project. 


In the case of X.400(1984) the usage of non ASCII body parts is 
mostly effected by bilateral agreement between recipient and 
originator, through use of body part 14. In practice this restricts 
the exchange of non ASCII body parts to those cases where the 
recipient and the originator use the same bilateral agreement or else 
the originator includes an ASCII message explaining the included 
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content type. Besides IPM there is a growing usage of EDI on top of 
X.400 (1984). 


With the above X.400(1984) deficiencies in mind, X.400(1988) has been 
specified by the CCITT / ISO to meet new user demands. X.400(1988) 
provides support for various different body parts, enhanced security 
features, international character set support capabilities and 
support of X.500 Directory Services. Due to the technological 
potential of these standards to satisfy user needs for new messaging 
services, the R&D community has been experimenting and piloting 
X.400(1988) and X.500 (1988) services. As there is a strong 
dependency of X.400(1988) messaging upon X.500 (1988) directory 
services, the necessary precondition to supply these user demands is 
a deployed and operational X.500 (1988) directory service. Piloting 
and deployment of the X.500(1988) directory service within the R&D 
community has been successfully initiated and co-ordinated by the 
COSINE and the VALUE PARADISE projects. 


Similarly, secure messaging has been addressed by the VALUE PASSWORD 
project and the RARE and IETF communities. Work to solve problems 
related to directory support of X.400(1988) messaging has been 
pursued within the IETF and RARE. The relevant RARE and IETF work 
groups (e.g., RARE WG-MSG, IETF MHS-DS, etc.) have also worked to 
produce any needed enhancements to the base X.400 (1988) and 
X.500(1988) standards. Last but not least it should not be 
overlooked that X.400(1988), as compared to X.400(1984), provides a 
comprehensive basis for gatewaying to and from RFC 822 / MIME / PEM 
and PC LAN messaging services. To that respect the IETF has defined 
standards for gatewaying Multimedia mail between RFC 822 / MIME / PEM 
and X.400(1988). As RFC 822 / MIME / PEM is now being deployed on the 
Internet, deployment of X.400(1988) services is needed to assure 
multimedia and secure messaging connectivity for the European R&D 
community. 


5. Possible solutions for providing globally pervasive messaging 


As can be now seen, a correlation of the present situation to the 
requirements of the user, shows that the current messaging services 
do not match the needs of users. To try to meet these needs a number 
of developments within various messaging technology areas are 
occurring. The following messaging technological areas, due to the 
present installed user base within the R&D community, are considered 
relevant: 


—- PC LAN E-mail systems such as Lotus cc:Mail, Microsoft Mail 
and Novell MHS 

- RFC 822 / MIME / PEM E-mail services 

- X.400 (1988) messaging services 


RARE WG-MSG Task Force 88 [Page 12] 


RFC 1616 X.400(88) for European Academics and Research May 1994 


Ongoing developments within each of the above technological areas 
provide new messaging options for the R&D community. The ability of 
each technological area to provide solutions for user and service 
provider requirements is summarised within this chapter. 


5.1. PC LAN E-mail systems 


Currently the usage of PC LAN E-mail systems is mostly for internal 
communication within an organisation. External connections, if 
present at all, to public service providers or other organisations is 
mostly through gateways to X.400(1984) or RFC 822. The use of a PC 
LAN E-mail system in terms of an infrastructure for interconnecting 
E-mail systems of different hues is not common within the Research 
community. Recent experience, from amongst others the Dutch Research 
network - SURFnet - [14] and the Norwegian Directorate for Public 
Management - Statskonsult - [18], has shown that a number of problems 
(i.e., limited functionality, high operational management cost, etc.) 
can be expected should these PC LAN E-mail systems be used as an E- 
mail infrastructure. (The use of native X.400 protocols for PC LAN 
E-mail systems would avoid the usage of gateways and would thus 
alleviate many of these problems.) A summary of those problems and 
some relevant issues follows: 


- Interconnecting heterogeneous PC LAN messaging systems 


One very distinct benefit for E-mail users of all hues is the 
potential to integrate heterogeneous PC LAN messaging systems with 
a minimum loss of service (e.g., multimedia services) by 
connecting them via X.400(1988) (or RFC 822/MIME/SMTP) . 
X.400(1988) is already being used, or under active development, 
for connecting together PC LAN messaging systems in a number of 
environments (e.g., Apple Macintoshes, DEC, Microsoft, Lotus, 
etc.). This tendency to gateway PC LAN messaging systems via 
X.400(1988) will increase and is one of the benefits that 
X.400(1988) brings to global multiprotocol messaging. 


—- Multimedia and binary data support 


The benefit of E-mail systems using these PC LAN systems is that 
the user interfaces are usually well integrated in the users 
standard working environment. Using a proprietary protocol these 
systems allow not only text (ASCII) but also binary, word 
processor, video, audio and other types of files to be 
transported. To reap the benefits of this multimedia / binary data 
transfer it would normally require that the same type of gateway 
is used by sender and receiver. Transporting these same files to 
another type of PC LAN E-mail system is not possible through the 
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current gateways without some information loss. In effect PC LAN 
E-mail system’s X.400 (or RFC 822) gateways from different vendors 


perform acceptably only for text body parts. True heterogeneous 
multimedia PC LAN messaging needs gateways to X.400(1988)’s 
service. 


- Application Programming Interfaces 


To help solve the problem of portability for Mail Enabled 
Applications Microsoft, Lotus, Novell, XAPIA and X/OPEN have been 
working on a number of standards for the Application Interface to 
mail transport protocols (i.e., Mail Application Programming 
Interface - MAPI, Vendor Independent Messaging - VIM, Common Mail 
Calls - CMC). These efforts are structured independent of the 
existing ’Wide-Area’ or inter organisational E-mail protocols of 
X.400(1984) and RFC 822. However the MAPI, VIM and CMC efforts, 
due to their proposers (respectively Microsoft, Lotus and X/OPEN), 
do look like they will provide the stimulant to various software 
developers to develop more portable applications plus allow the 
rich functionality of X.400(1988) to be accessed by these 
applications thus reducing the need for gatewaying to X.400(1988). 


— Security 


As the PC LAN E-mail systems require gateways for connectivity, 
they pose a problem with regard to encrypted messages. Gatewaying 
of secure messages is normally not possible. The gatewaying of 
secure messages is a general problem of gatewaying from one mail 
system to any other system and is not specific to PC LAN E-mail 
systems. 


- Directory Services 


To date mostly proprietary directory services have been deployed 
that do not match the needs of the users in terms of access 
controls for data, distributed and decentralised across 
organisations. X.500 based services promise solutions to such 
needs. As a result various suppliers have announced support of 
X.500 directory services for their E-mail products. However, 
should these interfaces be delayed then support of an inter 
organisational ’/White Pages’ services requires either, 


- directory information exchange products (i.e., directory 


gateways) deployed between a proprietary system and an X.500 
directory system 
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- gateways between de-facto market based proprietary 
standards, such as Retix Directory Exchange (DX) or 
Soft*switch’s Directory Synchronisation (DS), and X.500 
protocols 


- duplicated directories i.e., one proprietary and one X.500 
need to be operated. 


It should be stressed that gatewaying mechanisms and products are 
often problematic due to the lack of an open standard on the 
proprietary messaging system and or directory system. (As an aside it 
is thus essential to establish an operational X.500 infrastructure, 
including E-mail user interfaces that can transparently access this 
Directory Service, as soon as possible.) 


RFC 822, MIME and PEM services 


RFC 822 messaging services are widely deployed within the R&D 
community. There is ongoing work to extend RFC 822 to meet user 
requirements. Some of these extensions are elaborated upon within 
this chapter. 


- Distribution lists 


RFC 822 allows for the usage of DLs. Management of DLs is not 
(yet) standardised. 


- RFC 822 multimedia messaging via MIME 


With the arrival of MIME, the RFC 822 service has an additional 
protocol standard that addresses Multimedia messaging very 
comprehensively. In terms of user needs, MIME now allows messaging 
body parts to comprise multinational character sets and binary 
data. Multi-body part messages are also supported. One of MIME’s 
real strengths, in terms of deployment within the existing RFC 822 
service, is that it achieves its goals by overlaying its services 
over the existing RFC 822 service and thus mandating no changes to 
the in place RFC 822 infrastructure. This greatly simplifies the 
MIME deployment. 


- RFC 822 secure messaging via PEM 


Just as MIME has brought multimedia messaging to RFC 822 services, 
Privacy Enhanced Mail (PEM) is bringing secure messaging to RFC 
822 services. PEM also has used the same approach as MIME to 
deploy secure messaging within RFC 822 services; overlay PEM 
services over the existing RFC 822 services without requiring 
changes to the RFC 822 infrastructure. PEM brings confidentiality 
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and integrity of messages to RFC 822 users. However a number of 
problems with PEM, and X.400(1988) as well, still need to be 
solved before secure messaging can be considered to be an 
operational service. These problems are independent of the secure 
messaging protocol (i.e., PEM or X.400(1988)) and deal mainly with 
distribution of secret keys to the end users. There is very active 
work going on within the IETF to solve these problems. 


—- MIME and PEM 


There are still problems for messages that are simultaneously a 
multimedia message, as per MIME, and a secure message, as per PEM. 
A PEM encoded MIME message does not allow gatewaying to other 
messaging environments and therefore does not allow any of the 
features inherent within MIME to be exploited along the message 
path. A MIME message that contains PEM encoded body parts can be 
gatewayed but the integrity of the entire message is then not 
guaranteed. This is a real deficiency of both existing approaches 
as it is essential that users are able to simultaneously use 
multimedia and secure messaging. However, once again, the IETF is 
working very hard on solving these problems and solutions can be 
expected, although the solution of the gatewaying of PEM messages 
to other E-mail systems is still unclear. 


- Dynamic and distributed messaging routing via the Domain Name 
System (DNS) 


RFC 822 messaging benefits greatly by having a dynamic and 
distributed mechanism to assist in message routing i.e., Domain 
Name System (DNS). With the support of the DNS, RFC 822 MTAs are 
able to directly route to other RFC 822 MTAs and thus deliver 
messages with a minimum of delay. In practice mail often still 
traverses multiple RFC 822 MTAs for a number of reasons e.g., Mail 
Hubs provided for users who turn their machine off when they go 
home, Firewall Hubs for security reasons, etc. However it is 
commonly accepted that between RFC 822 mail hubs the delivery of 
messages is very fast. Typically resolution of routing decisions 
occurs in less than one minute and very often within seconds. In 
general the DNS service is a very valuable service that functions 
well in practice. 


- Support for Character sets 


Together with the MIME specification for content types, an 
extension for RFC 822 headers was defined that allows for usage of 
multiple character sets in names, subject etc. in RFC 822 headers 
[9]. This allows (European) users to use their preferred character 
set to support their language not only in the contents of a 
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message but also in the headers. 
- MIME capable gateways 


It is clear that to provide a seamless service to all users 
regardless of whether they are using RFC 822 or X.400 services, a 
widely available set of well run and standardised RFC 822 to X.400 
gateways must be in place. For InterPersonal Messaging (IPM) based 
on US ASCII there are already a large number of such standardised 
(i.e., X.400-to-RFC 822) gateways deployed. To ensure seamless 
gatewaying between MIME and X.400 multimedia users, these existing 
text based gateways must be either upgraded to or replaced with 
multimedia messaging gateways. A number of proposed Internet 
standards to solve these problems, for both X.400(1984) and 
X.400(1988) and generated within the MIMEMHS work group of the 
IETF, have been completed [4]. 


- Access to fax, teletex, telex or physical delivery 


For the moment, there is no standardised way for RFC 822 users to 
access gateways to the above services except by indirect access to 
X.400(1988) systems (i.e., concatenated gateways of RFC 822 to 
X.400(1988) and then onwards to the appropriate X.400(1988) Access 
Unit). Although even this indirect method would require some 
further work on standardising mappings between RFC 822 addresses 
and X.400(1992)’s X.121 addresses. As well some experiments within 
the RFC 822 world are occurring on routing fax messages. 


- Operational support 


Generally, RFC 822 messaging services are delivered on a ’best 
effort’ basis and thus service level agreements requesting 
stringent response times to operational problems or guaranteed 
delivery times for messages are difficult to agree. This phenomena 
might be a result of the distribution and delegation of authority 
to organisations updating the RFC 822 MTA’s routing mechanism 
i.e., DNS. As a result it makes it hard to reach a ’one stop 
shopping’ agreement for RFC 822 messaging services. 


- Notifications 


The RFC 822 service provides a minimum amount of base protocol 
support for messaging users. It could be argued that the RFC 822 
protocol is simplified by this choice and thus software that 
implements the standard need be smaller in size and easier to 
build. However some features e.g., delivery & receipt 
notifications and UA capabilities registration, would be commonly 
accepted as being desirable from a user standpoint and thus 
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desirable extensions to RFC 822. Some operational problems 
relating to reliability could be minimised by technology that has 
a standardised support for positive and negative notifications of 
messages. RFC 822, as compared to X.400, technology does not yet 
support positive notifications (although there is work starting 
within the IETF to extend RFC 822 to support delivery 
notifications). However within RFC 821 transport system (i.e., 
SMTP) there are standardised negative notifications that work 
well. Alternatively X.400 technology, deployed over TCP/IP (using 
STD 35, RFC 1006), may help to address the lack of adequate 
service quality - notification support - when using E-mail within 
the Internet. 


- Portability of RFC 822 products 


There are only a few mailbox formats in general use by RFC 822 
software, one being the ’bin/mail’ format and the other '’MH’ 
format. This ’standard’ mailbox format is a definite benefit for 
RFC 822 users as it allows them to change RFC 822 UAS (e.g., 
upgrading to MIME RFC 822 UAs) whilst not compromising or 
converting their existing archived mail, which may comprise 1000s 
of archived messages. 


— System support for RFC 822 products 


Normally, RFC 822 MTAs and UAs come pre-installed on UNIX 
workstations. As a result, users are spared the effort of 
installing RFC 822 MTA software. If for some reason, a user or 
mail administrator should wish to install a different MTA or UA to 
the pre-installed system, there exists a large number of easily 
available (i.e., via widespread distribution amongst many FTP and 
other information servers) public domain RFC 822 MTAs and UAs. 


Both of the above points encourages the spread and eases the 
installation of software for the RFC 822 messaging service and in 
many ways explains the size and importance of the installed base 
of RFC 822 systems. To illustrate the extent of RFC 822 / MIME 
products, a non-comprehensive list of available MIME enhanced RFC 
822 products follows; ELM 2.4, MH 6.8, Sun Mailtool, HP Mpower 
Desktop, Lotus cc:Mail (unconfirmed), Zcode Zmail, Frontier 
Super-TCP for Windows, PMDF (VAX VMS), Pine, C-Client (library 
routines), Metamail (viewer only), Andrew-MIME gateway. 


- UA capability registration 
The IETF MHS-DS working group has defined how X.400 and RFC 822 


User Agent capabilities can be stored in X.500 directory services. 
This work is still ongoing. 
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X.400 - 1984 and 1988 


400 (1988) substantially upgrades and enhances the X.400 (1984) 


standards. A number of new functions have been incorporated within 


X 


400 (1988). A description of the most important features of X.400 - 


1984 and 1988 - follows. 


RARE 


Notifications 


X.400 (1984) provides four notifications - positive and negative 
delivery notifications and positive and negative receipt 
notifications. These notifications allow users to ensure 
successful message delivery or that the message was read. The 
delivery notifications are also used by service operators in their 
fault escalation procedures. 


Binary Data Transfer 


X.400(1984) allows binary data transfer to be transported without 
the necessity of character encoding. The ability to transfer files 
of whatever type is a valuable end user service. As well the lack 
of any necessary character encoding allows users to utilise the 
received data without needing any character decoding software. 


Multiple Body Parts 


The ability to send multiple body parts within one message gives 
the user the ability to send multiple logical components within 
one message. This is a natural mechanism for users as it mirrors 
the real life situation of being able to send within one message, 
a letter, a word processor file, a spreadsheet file, etc. 


Feature rich messaging model 


The features of X.400 are very rich. This provides benefits for 
users as vendors are able to provide applications that can utilise 
these extensive features in an interoperable manner due to the 
standardisation of the features within X.400. 


Clear messaging model 


X.400(1984), as one of its most wide reaching achievements, has 
popularised within the market a consistent and clear model to 
describe message handling systems. The decomposition of a message 
handling system into UAs, MSs, MTAs, MTS - ADMDs and PRMDs and 
Access Units / Gateways has proved to be an extremely useful tool 
for users and vendors to understand and communicate their 
messaging needs or solutions. 
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- Multiple lower layer networks 


X.400 has embraced the concept that there are different technology 
lower layer networks. This concept even allows multiple logical 
networks of the same technology to be supported. X.400 allows the 
messaging service to fully function even though the underlying 
network is varying. In the real world of a non-uniform network 
layer this is an extremely powerful capability. 


The list of major X.400(1988) extensions to X.400(1984) follows: 
- Distribution Lists (DLs) 


A powerful mechanism for arbitrarily nested Distribution Lists 
including the ability for DL owners to control access to their 
lists and to control the destination of non delivery reports. The 
current endemic use of DLs in the R&D community makes this a 
fundamental requirement for any service. X.400(1988) uses X.500 to 
provide a standardised support for DLs, although there have been 
some needed standardised enhancements relating to the CCITT 
defined DLs by the IETF MHS-DS work group. The provision of 
powerful nesting capabilities plus management mechanisms for DL 
owners within X.400(1988) DLs are features providing attractive 
benefits for users and DL managers. There is already ’running 
code’, via the COSINE Explode project which is implementing the 
MHS-DS based enhancements. The project builds upon experience 
gained within a number of networks e.g., JNT and provides: 


- implementation of MHS-DS enhancements related to the 
X.400(1988) DLs 

- archiving of messages received by a DL. 

- access by users to the DL archive via e-mail. 

- subscription to a DL by users via e-mail. 


- Message Store (MS) 


The Message Store provides a server for remote UAs on workstations 
and PCs enabling messages to be held for their recipient, solving 
the problems of non-continuous availability of such UAs. The 
message store allows mobile workers, small offices and local 
schools to become active messaging users in a cost effective 
manner. The message store provides powerful selection mechanisms 
allowing the user to select messages to be transferred between the 
store and the workstation. This facility is not catered for 
adequately by the P3 protocol of X.400(1984) and provides a major 
incentive for transition. 
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- X.500 Directory names 


Support for use of Directory Names in MHS will allow a transition 
from use of O/R addresses to Directory Names when X.500 
Directories become widespread, thus removing the need for users to 
know about MHS topological addressing components. 


The ability for X.400(1988) messages to contain directory names 
instead of the O/R addresses is a powerful feature for users as it 
frees them of the necessity to insert O/R addresses containing 
routing information but allows them to insert the more natural 
directory names. However, the management of the large amounts of 
distributed data contained within the directory is problematic in 
that it involves a number of organisational issues and not just 
software issues. A number of X.400(1988) UAs which allow users to 
insert directory names instead of O/R addresses have already been 
developed. 


- Support for EDI 


Through the definition of Pedi, as defined in X.435, X.400(1988) 
offers integrated support for EDI messaging. The CEC TEDIS program 
has mandated X.400 as the main carrier for EDI, and standardised 
how EDI transactions are inserted into X.400 messages (i.e., Pedi 
and P2). This provides a strong incentive to provide native 
X.400(1988) services to users and applications thus encouraging 
commercial EDI traffic to migrate to X.400(1988). 


- Secure Messaging 


The provision of secure messaging services including 
authentication, confidentiality, integrity and non-repudiation as 
well as secure access between MHS components are important 
benefits for the R&D community. The base standards are adequate 
for security, however organisational and software issues need 
still to be solved. Organisational issues of globally scaling the 
distribution of secret keys is still unsolved. Software issues of 
how end users will be able to comfortably and securely input 
secret keys of length 512 -> 1024 bits into security software need 
to be solved. 


— Multimedia 


The definition of a number of additional body parts plus the 
ability to define new body parts (e.g., Word Processor formats, 
Excel documents, etc.) provides the basis for multimedia services 
over X.400(1988). As well, the newly defined General Text body 
part supports multinational character sets (except for ISO 10646) 
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without the need for transmission encoding. However, unlike MIME, 
X.400(1988) is only specifying a standard for multimedia 
messaging. To achieve multimedia document exchange, there is a 
further text exchange standard such as ODIF, Hytime, etc., needed. 


-— Character set support for extended addressing 


A highly desirable potential benefit for European R&D users is 
provided by the extended character set support(i.e., T.61) within 
addresses. Nearly all European languages, except for Greek and 
Cyrillic, are supported by the T.61 teletex encoding. Further 
extensions to X.400 for support of extended character sets has 
been defined by the RARE WG on character sets and RARE WG on 
messaging [15]. 


- Physical Delivery Services 


This standardised method for a message to be delivered on a 
physical medium, such as paper, through the normal postal service 
is useful when trying to reach a very wide number of (non- 
electronically reachable) recipients. In effect this service 
provides an ability to ’go the last mile’ and communicate with 
users previously not easily reachable e.g., farmers, etc. 


- General Extension Mechanism 


One of the major assets of X.400(1988) is the extension mechanism. 
This is used to carry most of the extensions defined in these 
standards, but its principal benefit will be in reducing the 
trauma of transitions to future versions of the standards. 


Provided that implementations of the X.400(1988) standards do not 
try to place restrictions on the values that may be present, any 
future extension will be relayed by these implementations when the 
extension is not critical, thus providing a painless migration to 
new versions (1992 and beyond) of the standards. 


- UA Capability Registration 


With the extra functionality available to X.400(1988 and 
especially 1992) UAs (i.e., extra non-IA5 body parts, secure 
messaging, etc.) it is expected that the demand to register UA 
capabilities will increase. In that respect X.400(1988)’s ability 
to query X.500, where such capabilities would be stored, is a 
Significant potential benefit for users. 
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- X.500 support for MTA routing 


The piloting of X.500 to support MTA routing within the R&D 
community has already commenced, on a small experimental scale, 
via the Longbud project co-ordinated by the IETF MHS-DS work 
group. Some concrete benefits promised by X.500 based routing are: 


- routing based upon content types, security, transport stacks 
and other criteria allow optimum routing paths to a 
destination MTA to be chosen. (There is presently no such 
Similar capability within the DNS). 


- allowing the routing information to be inserted and modified 
in a distributed manner reduces (if not eliminates) the 
necessity of central distribution of static routing tables. 
The consequent reduction in manpower to co-ordinate MTA 
routing plus the increase in scalability of the service 
allows a truly global messaging service to be put in place. 


6. Migration to X.400(1988) 
What is clear from the previous chapters is that; 


-— The resources, human or financial, to operate multiple wide 
area messaging services connecting together independent 
organisations are high. As such it is desirable to try and 
keep to a minimum the number of such services. This statement 
is true for the R&D community but is also highly likely to be 
valid for the general European industry. 


- There are two publicly available technological standards 
that can be used by open communities, such as the R&D 
community and public service providers: the X.400(1984 and 
1988) recommendations and the Internet RFC 822 / MIME / PEM 
standards. 


-— There is an established very large global user base of 
Internet RFC 822 and X.400(1984) messaging services. Both 
services have their own momentum within different parts of 
the user community, both are still developing and growing 
fast. 


From the above discussion, it is clear that the infrastructure 
services that have to be supported within these open communities, and 
especially within the R&D community, are RFC 822 / MIME / PEM, 
X.400(1984) and X.400 (1988). X.400(1988) will be the preferred 
protocol for inter-organisational connection for European industry 
and government and parts of the European R&D community. RFC 822 / 
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MIME / PEM will be the preferred protocol suite for inter- 
organisational connection for the Internet community and, as products 
are already widely available, it is the preferred protocol for parts 
of the European R&D community. 


The goal of European pervasive messaging - incorporating Industry, 
Government and Academia - would be best accommodated and reached by 
the establishment of a single messaging service. However taking the 
above into account, this is not feasible, as X.400 and RFC 822 based 
services will be around for a long time to come. To increase the 
functionality of Wide Area E-mail services there is a clear necessity 
to: 


- migrate RFC 822 services to a RFC 822 / MIME / PEM service. 
A MIME based service offers more functionality to the user 
than a plain RFC 822 service. 


- migrate existing X.400 services to a X.400(1988) service. 
Due to the lack of scalability of the X.400(1984) service in 
terms of extra functionality, it will become increasingly 
difficult to meet the needs of research users of existing 
X.400(1984) services unless an X.400(1988) service is put 
into place. 


— provide a transparent gateway between X.400 (1988) and RFC 
822/MIME/PEM. For the European R&D community it is essential 
to have a transparent gateway between the X.400(1988) service 
and the RFC 822 / MIME / PEM service, thus ensuring 
connectivity between these two services with a maximum 
functionality. 


Such a gateway is technically feasible and it is an essential part of 
an unified E-mail service. Without such a standardised gateway the 
overall E-mail service would deteriorate. 


The lack of open standards for the PC LAN messaging systems 
discourages their use as ’backbone’ messaging technologies within 
open communities. However the products that these systems deliver to 
end users ensures that their already large share of the messaging 
market will continue to exist for some time. Thus it is also 
essential that strategies that allow these systems to be ’seamlessly’ 
integrated within the global messaging community are put in place. 
Not least due to the indications that the main messaging vendors are 
developing X.400(1988) and RFC 822/MIME gateways, a strategy to link 
these systems together via X.400(1988) and RFC 822/MIME should be 
developed. 
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To make migration to a X.400(1988) service feasible, extensive 
migration and coexistence options for various non-X.400 (1988) users 
have to be developed. Main issue in each migration strategy remains 
the co-operation of the users. The migration needs to be user-driven, 
i.e., the users need to be convinced of the added functionality 
(versus the cost) of migrating towards X.400(1988). A detailed 
summary of the different issues and possible problems involved in the 
transition to a X.400(1988) based messaging service, with respect to 
what are commonly accepted as the four most important messaging 
services: RFC 822, MIME and PEM; X.400(1984); MAIL-11 and PC LAN 
messaging systems are presented in this chapter. 


6.1. PC LAN E-mail systems 


To provide coexistence and migration the usage of gateways is 
unavoidable. The quality of these gateways, with regard to: 


- Transparency (gatewaying multimedia messages, transparent 
addressing) 

- Manageability 

— Reliability 


has to be improved. Ultimately through usage of APIs like MAPI and 
CMC, the users interface hopefully will become independent of the 
mail protocol that is used. It will then be expected to be possible 
to let the user retain his preferred mail user interface, while the 
protocol used migrates to X.400(1988). 


Via the use of these APIs it may be possible to access the full 
features of X.400(1988) while retaining a proprietary PC LAN UAs. 
This way a PC LAN can be easily connected to a X.400(1988) backbone. 
This usage of APIs to ease migration for end users should be 
encouraged. 


The migration of PC LAN E-mail systems will likely be driven by the 
commercial vendors of mail enabled applications, such as UAs, Work 
Group Systems, Task Flow Systems plus X.400(1988) MTAs and gateways 
able to serve these applications via these new APIs. 


6.2. RFC 822, MIME and PEM services 


A migration from RFC 822 / MIME and PEM services to X.400(1988) needs 
to be formulated for those management domains that wish to effect 
this change. As well a long term transition and coexistence phase 
needs to be accommodated due to the existing base of RFC 822 users. 
An understanding of the issues involved in migrating from RFC 822 to 
X.400(1988) messaging services is essential before any rational 
decisions on migration can occur. Certainly one, if not the main, 
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issue in such a migration is that the migration must allow a 
transition period where maximum functionality between both services 
exists. Any migration must be aware that RFC 822 messaging services 
are a ’moving target’. 


- Ease of transition as perceived by an RFC 822 user mandates 
that the user’s existing mail folders are converted into the 
new mail product’s folder system flawlessly. 


— The RFC 822’s user’s e-mail address should remain the same 
even after a migration. (i.e., the user keeps the same address 
that has two different notation forms: X.400 and RFC 822). 


- Users contemplating a migration will be stimulated to do so 
if they experience no loss of service as regards MIME and 

X.400(1988) gatewaying; are still able to insert RFC 822 

style addresses into the X.400(1988) UA and are provided with 


high performance X.400-to-RFC 822 gateways. 


-— The added connectivity provided by X.400(1984 or 1988) 
gateways to fax, telex, post etc. plus additional X.400 users 
that the user is able to reach easily (whilst not losing 
connectivity to RFC 822 addresses) plus the additional 
functionality of X.400(1988) possible when communicating with 
X.400(1988) users will also act as a stimulant toa 
migration. 


- The functionality provided by RFC 822 / MIME products will 
be the yardstick that an RFC 822 user compares an offered 
X.400(1988) product with. As such X.400(1988) products must 
provide some basic and important functions like: Character 
Set support via GeneralText; Multimedia capability via 
Extended Body Parts; low message delays within the seconds 
time scales and ease of configuration of products. At present 
there is no RFC 822 equivalent to X.400 delivery and receipt 
notifications and as such these functions are seen as extra 
functionality by the user. 


- A follow on to the extra functionality point above is that 
present RFC 822 users, most likely commercial users, that 
want to be able to use EDI or other mail enabled applications 
that need security, message audits and positive confirmations 
will be encouraged to migrate to X.400(1988). A decision to 
use X.400(1988) in this case would be especially attractive 
for those commercial RFC 822 users that are already operating 
multiple lower layer networks. As X.400(1988) accommodates 
multiple different network layers easily, the cost to migrate 
could be considered quite small. 
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6.3. X.400(1984) services 


A number of problems can be identified in a migration from 
X.400(1984) to X.400(1988). They are summarised as, 


- OSI supporting layers are mandatory in the 1IS010021 MOTIS 
standard, while the support of the complete OSI stack (normal 
mode ) is optional in the otherwise equivalent CCITT 
X.400(1988) specifications. It is thus recommended that the 
migration from X.400(1984) should be straight to ISO 10021 
i.e., straight to use of the full OSI stack with normal mode 
RTS. 


-— There is a negative impact on quality of service caused by 
implementation decisions related to the ’General Extension 
Mechanism’. To overcome this negative impact no minimal 
X.400(1988) MTAs, which relay the syntax but understand none 
of the semantics of extensions, should be used. 


— All X.400(1988) MTAs should generate reports containing the 
extensions that are present in the original message and route 
such reports through the DL expansion hierarchy where 
appropriate. 


- Choice of standards to be used within mixed X.400 (1984 and 
1988) management domains needs to accommodate in one option 
the danger of undetectable routing loops from incorrectly 
configured routing entries and in another option the problem 
that systems that have fixed the routing loop problem may not 
all be consistently implemented due to ambiguities within the 
standards. The choice of which of these two options a 
management domain uses internally has no impact on external 
management domains. 


- DDA support is needed by X.400(1984) systems to address 
X.400(1988) Common Name Attribute users [2]. 


— Minimum loss of service quality mandates that downgrading of 
X.400(1988) body parts to X.400(1984) bodyparts be done 
according to the MIMEMHS specifications [4]. 


- To enhance connectivity to both X.400(1984 and 1988) 
management domains without degradation of X.400(1988) 
service, management domain entry points that support both 
X.400(1984 and 1988) are recommended. 
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- Ensuring that no X.400(1988) MTAs transit via X.400 (1984) 
MTAs. This allows no degradation of X.400(1988) service 
quality [17]. 


The consequence of the last point is that the existing European 
Research X.400(1984) - formerly COSINE MHS - MTA RELAY backbone 
should be one of the first MTA communities to migrate to X.400(1988). 


6.4. Mail-11 services 


The Mail-11 (also known as DECnet mail) e-mail service is the major 
e-mail service used within the High Energy Physics and Space Physics 
Analysis Networks (i.e., HEPnet and SPAN) and is the native e-mail 
service present on VMS operating systems. The Mail-11 service is 
considered the most popular service by the large HEPnet / SPAN 
community. Mail-11 provides also large and easy to use gateways to 
other E-mail protocols, like X.400 (84), RFC 822 (SMTP over TCP/IP, 
DECnet and X.25, BSMTP over NJE), and PC LAN E-mail services. 


Jointly with the "old style" Mail-11 UA, the DECnet Phase V (OSI 
CLNS) service provides the native capability to run X.400 (88) and 
X.400(1984) services. There is thus the potential for X.400 (88) 
services to become available as soon as the HEPnet / SPAN community 
migrates to DECnet Phase V. However the availability of VMS based UAs 
for the X.400(1988) service is still very limited and is thus forcing 
users to continue to stay with their Mail-11 UA (and thus the Mail-11 
service). 


Users in HEPnet / SPAN are demanding enhancements to their mail 
services to support multimedia and delivery / read receipt services. 
This is a strong driving factor for good X.400(1988) UAs to become 
available soon to allow users to properly use the available 
X.400(1988) service of DECnet Phase V. 


7. Benefits of migrating to X.400(1988) and the involved costs 


The actual as compared to the potential benefits of migrating from 
one’s existing mail system to a new mail protocol is very dependent 
on good products, good organisation of the migration and a degree of 
commitment that the transition is worth the cost. Quantifiable and 
accurate cost / benefit ratios for such a migration are not possible 
within the decentralised European R&D environment and as such are not 
generated. 


We have in this chapter listed the benefits that such a migration to 
X.400(1988) achieves. We have also given an indication of the 
relative costs of such a migration. Provided that there are good 
products, and taken in conjunction with the recommendations of 
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Chapter 8 and Appendices A and B, the task force is confident that 
these potential benefits will translate into actual benefits and be 
worth the costs incurred. 


*Benefits* 


Below is a list of non-technically oriented benefits and the features 
of X.400(1988) that enable these benefits to occur. The benefit of, 


- efficient and innovative communication within Europe is 
assisted by establishing an X.400(1988) messaging service 
that integrates European industry, government and academia; 


- an increase in business efficiency by the use of EDI (for 
example automatic processing of business forms, exchange of 
business contracts, etc.) is enhanced by the security aspects 
of X.400(1988) i.e., non-repudiation, authentication, 
confidentiality, integrity plus secure access between MHS 
components. 


- allowing European users to communicate in their native 
European languages is brought about by the GeneralText body 
part of X.400(1988). 


- remote users and Small and Medium size Enterprises (SME) 
using e-mail for electronic commerce is encouraged by 
reducing the entry level costs for use of e-mail. An SME’s 
use of Remote UAs in conjunction with a service provider’s MS 
-instead of purchasing their own MTA - is accommodated by 
X.400 (1988). 


— providing global messaging for all e-mail users, but 
recognising the existing market realities of heterogeneous e- 
mail systems, would be enhanced by the establishment of 
gateways to X.400(1988). 


- being able to recover costs by charging and accounting for 
messaging services back to users - this is especially 
important for commercial service providers - is brought about 
by the message auditing capabilities of X.400(1988). 


—- communication with users that have no access to E-mail (for 
example if such users are defined within Distribution Lists) 
is enhanced by X.400(1988)’s support for gateways to physical 
delivery, fax, telex, teletex, etc. 
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- building upon the existing X.400(1984) infrastructure (i.e., 
reduction of establishment costs) is brought about by 
migrating the X.400(1984) infrastructure to X.400(1988). 


- a reduction in manpower (and thus costs) to manage a global 
messaging service is brought about by the messaging service’s 
ability to utilise the global distributed directory for 
management information. 


- the messaging infrastructure to meet new user requirements 
is enhanced by the support for General Extensible Mechanism. 


- making E-mail more user friendly is brought about by a 
messaging service that allows the use of the more natural 
directory names in E-mail addresses. 


- increased effectiveness of messaging by the use of DLs is 
brought about by X.400(1988)’s support of powerful nesting 
capabilities and management for DLs. 


—- an increase in global message delivery performance and 
reliability is enhanced by the ability of X.400(1988) to use 
X.500 for MTA routing. 


— more messages being successfully delivered to mobile or 
transient users is enhanced by the provision of the Message 
Store. 


- multimedia use is enhanced by the ability to define new body 
parts and to support multiple types of binary data such as 
audio and video. 


- establishing optimum and seamless conversion of messages 
based upon the capabilities of a user is brought about by the 
ability of X.400(1988) to act upon UA capabilities. 


*Costs* 


The generic costs to establish an X.400(1988) pilot service can be 
broken down into: 


- a cost per backbone of RELAY MTAs (as used by the European 
research community - the former Cosine MHS service), 

- a cost per service provider, 
a cost per organisation, 

- a cost per user and 
a cost per user MTA for migrating to X.400(1988). 
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To bring about the benefits, mentioned above, certain costs will be 
incurred and they are summarised below: 


- Cost per backbone of RELAY MTAs (as used by the European 
research community - the former Cosine MHS service) 


- The equipment costs of migrating backbone RELAY MTAs. 


— The establishment of some sort of organisational / 
project group to oversee a backbone RELAY MTA pilot. 


As most of the RELAY MTAs are already X.400(1988) capable, there 
is already a MHS Co-ordination service in place that could be used 
for this function and the number of backbone RELAY MTAs is less 
than 100 in number the cost for migrating the RELAY MTA backbone 
is considered relatively low. 


- Cost per service provider 


- If the RELAY MTA backbone (formerly Cosine MHS) is 
migrated towards X.400(1988), then the remaining cost 
for a service provider for migrating the infrastructure 
towards X.400(1988) is relatively low. 


- The operational costs for organisational issues, for 
example dealing with OID registrations, is low if 
national R&D service providers act as a clearinghouse 
for their own national R&D institutions e.g., 
Universities. 


- Cost per organisation, end user and MTA 


— The operational costs of migrating end users and their 
MTAs in management domains to X.400(1988) are higher 
than the costs involved with migrating the 
infrastructure. This is due to the order of at least 10 
to 100 times more MTAs, as compared to the service 
providers, that would be involved with a migration to 
X.400(1988). As the infrastructure needs to migrate 
first, the costs for the end user MTAs can be reduced 
by profiting from the migration experience of the 
service providers. 


-— The education and training costs for users and system 
managers are significant, due to the amount of end 
users and end user MTAs. Any marginal cost savings per 
user which can be made, e.g., by deployment of automated 
tools, should be considered due to the large overall 


RARE WG-MSG Task Force 88 [Page 31] 


RFC 1616 X.400(88) for European Academics and Research May 1994 


savings that accrue. 


- The costs of any potential disruption of the end user’s 
messaging service are high - due to the huge numbers of 
end users involved - and as such only a very well 
managed, phased and planned migration should be 
considered. 


- Software costs 


- The costs for software development are outside the 
scope of this report. However it is clear that cost 
needs to be incurred in order to provide software that 
is easy to install and use. As a result of the work of 
the task force a list of possibly needed components and 
likely changes to existing components can be proposed, 


Modifications, but not new developments, to 
software for: 


— X.400(1988) MTAs, X.400(1988) UAs, DSAs, 
DUAS and MSs. 


New software developments for: 


— MIME to MHS Gateways, X.400(1988) network 
management, mailbox conversion, PC LAN 
directory synchronisation, PC LAN gateways 
and UA capability registration. 


—- The distribution costs for any new software (for the 
European R&D community) are low if usual academic 
distribution methods - FTP servers, E-mail Based 
servers, Gopher, World Wide Web and Archie - are used. 


*Summary* 


Migration towards a X.400(1988) service needs to evolve from the 
inside (the messaging backbone) outward (to the end user MTAs and end 
users themselves). Due to the numbers involved both the costs and the 
benefits associated with the migration increase as the migration 
evolves towards the end users. 


The benefits of migrating to a X.400(1988) service are a feature rich 
well defined open standard with high functionality , scalability, use 
of directory, multimedia and secure messaging capability. The costs 
for migrating a RELAY MTA backbone can be considered relatively low 
whilst the migration of end user MTAs and the migration of the end 
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users themselves are relatively high. These costs should of course be 
balanced against the cost of a disrupted service that one might get 
if no migration occurs at all and the current service (e.g., 
X.400(1984)) reaches the limits of its scalability and/or 
functionality. 


It is important to realise that if end users themselves do not 
experience direct feedback of the benefits from X.400(1988), this may 
make the organisational motivation needed to effect such a migration 
difficult to achieve. In effect, the establishment of a pilot 
X.400(1988) service is and should be driven by the requirements of 
end users and thus achieving end user benefits - as listed above - 
must be given a higher priority within a X.400(1988) service than 
solely the extra service provider benefits. 


8. Main Recommendations 


The RARE WG-MSG Task Force on 'The Establishment of an X.400 (1988) 
Pan European Pilot Messaging Service’ has identified a number of high 
level recommendations for establishing such a 

service. The main high level recommendations are listed within this 
chapter. A more detailed elaboration of these main recommendations is 
given in Appendix A. Appendix A is provided for policy makers wishing 
more background on the main recommendations. As well, a list of very 
detailed guidelines, plus some issues requiring further 
investigation, is given in Appendix B. Appendix B will be especially 
useful for personnel seeking detailed technical guidelines which are 
consistent with the main high level recommendations. 


*Recommendations* 


- Establish a X.400(1988) pilot service encompassing European 
Commercial, Government and Academic bodies. Such a pilot 
service to be co-ordinated by using an industry forum where 
all parties could meet. The use of an existing forum, where 
user organisations are well represented, is desirable if 
commercial end users organisation’s requirements are to be 
met. The forum should also be open to non-European 
participants. 


—- X.400 (1988) end user services should be provided as well as 
a X.400(1988) backbone RELAY MTA service within a X.400(1988) 
pilot service. The end user services should be given a high 
priority. 


- Help an already emerging market place in X.400 (1988) 


products to prosper by ensuring that a suitable supply of 
high quality X.400(1988) public domain software is available. 
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The Internet has proven, that public domain software, free of 
any commercial restrictions, is further rapidly developed, by 
Small and Medium Size Enterprises (SMEs), into derivative 
products suitable for the commercial market. 


- Any pilot service should be well co-ordinated and result 
driven but utilise a distributed market oriented approach. It 
is considered very difficult to organise and plan such a 
pilot under the assumption of a single centrally funded body 
i.e., driven from the ’top’. A more ’market driven’ or 
distributed organisation is considered feasible, and likely 
to succeed, if all the market ’players’ are fully involved 
i.e., a ’bottom’ up approach. 


- For the academic community - and ever more for the 
commercial community - there is a business need to ensure near 
total and ’perfect’ integration with the existing and also 
evolving RFC 822 based services. 


- For the academic community a rapid migration of the existing 
X.400(1984) backbone RELAY MTAs, used within the European R&D 
X.400(1984) service, - formerly the COSINE MHS service - is 
considered urgent. This migration will provide a ’bootstrap’ 
path for academic organisations to internationally pilot 
X.400(1988) services. Such end user piloting is not 
considered feasible if X.400(1984) backbone RELAY MTAs are 
used for an X.400(1988) service (see Reference [17] for 
technical details). 


The report does not include any recommendations on development and 
deployment of RFC 822 / MIME / PEM related (pilot) services, as these 
are outside of the scope of the Task Force. However, since both 
X.400(1988) and RFC 822 / MIME / PEM will be developed and used 
within the European R&D community, such a pilot should also be 
considered. 


9. Security Considerations 


Security issues are not discussed in this memo. 
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11. Terminology 


ADMD 
ASCII 
ASN.1 
AU 
CCITT 


CEN 
CENELEC 
CEPT 
CONS 
COSINE 
DL 

DIS 
EMA 
EN 
ENV 
IEC 
IETF 
IPM 
IPMS 
IPN 
ISO 
JNT 
JTC 

MD 

MHS 
MHS-DS 


MIME 


MOTIS 
MTA 
MTL 
MTS 
NBS 
OSI 
PEM 
PRMD 
RARE 
RFC 
RFC 822 


RTR 
RTS 
WG-MSG 


Administration Management Domain 

American Standard Code for Information Exchange 
Abstract Syntax Notation One 

Access Unit 

Comite Consultatif International de Telegraphique et 
Telephonique 

Comite Europeen de Normalisation 

Comite Europeen de Normalisation Electrotechnique 
Conference Europeene des Postes et Telecommunications 
Connection Oriented Network Service 

Co-operation for OSI networking in Europe 
Distribution List 

Draft International Standard 

Electronic Messaging Association 

European Norm 

Draft EN, European functional standard 

International Electrotechnical Commission 

Internet Engineering Task Force [20] 

Inter-Personal Message 

Inter-Personal Messaging Service 

Inter-Personal Notification 

International Organisation for Standardisation 

Joint Network Team (UK) 

Joint Technical Committee (ISO/IEC) 

Management Domain (either an ADMD or a PRMD) 

Message Handling System 

Message Handling Systems use of Directory Service 
Working Group from the IETF 

Multi-purpose Internet Mail Extensions (extensions to 
RFC 822) [6] 

Message-Oriented Text Interchange Systems 

Message Transfer Agent 

Message Transfer Layer 

Message Transfer System 

National Bureau of Standardization 

Open Systems Interconnection 

Privacy Enhanced Mail [10] 

Private Management Domain 

Reseaux Associes pour la Recherche Europeenne 
Request For Comments (series of Internet publications) 
RFC describing Internet Message format for Electronic 
mail 

RARE Technical Report (series of RARE publications) 
Reliable Transfer Service 

RARE Working Group on Mail and Messaging 
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Appendix A - Elaboration on the main recommendations 


The main recommendations of the report are elaborated upon in more 
detail within this appendix. 


- In order to provide a globally pervasive messaging service, 
it is recommended to establish a well operated Pan-European 
X.400(1988) pilot backbone comprising MTAs and MSs, 
connecting partners within Industry, Commercial Service 
Providers, Academia and Public Bodies (CEC, National 
Governments, etc.). The pilot should be open to global 
participation. 


- In order to maintain the widest connectivity with the 
highest possible functionality, gateways should be installed 
that gateway between X.400(1988) and RFC 822/MIME. These 
gateways should follow the specifications of RFC 1327 [1] and 
RFC 1494 et al. [4]. Experience with these gateways should be 
fed back into the appropriate RARE and IETF Working Groups to 
improve the standards. 


- In order that the ’business needs’ of non-R&D organisations 
can be inserted at an early stage into the goals of the pilot 
and ensuring that the success of the pilot in meeting these 
goals can be measured and disseminated i.e., to encourage the 
active participation of non-R&D organisations within the 
pilot, it is recommended that an open forum comprising 
industry, service providers, public bodies and academia 
should be used. Preferably an existing forum where end users 
are heavily involved is desirable. 


- In order for meaningful co-operation between bodies affected 
by the pilot to occur and thus hopefully reducing unnecessary 
duplications, it is recommended that there are close liaisons 
and contacts between at least the IETF, RARE, EARN, EUnet, 
RIPE, Y-NET, EEMA, EMA, EWOS, OIW, CEN/CENELEC, ISO, CCITT, 
CEC and European governmental bodies and those involved 
within the pilot. The suggested mechanism for a meaningful 
liaison is that enough participants of the above 
organisations attend the common forum mentioned above. It is 
also suggested that as much as possible e-mail distribution 
lists be used to communicate between forum participants. 


- In order that the pilot have measurable results, it is 
recommended that the pilot shall be implemented in phases. It 
is considered that at least two phases are needed: 
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—- phase 1 - initial short start up phase with a small 
number of participants. The result of this phase is 
that any needed procedures, co-ordination mechanisms, 
etc. are put into place for the large scale piloting of 
phase 2. 


- phase 2 - phase with a wide Pan-European participation. 
The result of this phase should be a proof of scaling 
of the pilot X.400(1988) service i.e., the goals of the 
pilot as defined in Chapter 1 are met. It is expected 
that upon successful completion of this phase a natural 
evolution to a global deployment of a X.400(1988) 
service will have started. 


- In order to rapidly complete phase 1 of the pilot and that 
the pilot is at least Pan-European in scope, it is 
recommended that; a number of R&D service providers, one each 
from several European countries; at least 2 North American 
R&D service providers; at least 1 Japanese R&D service 
provider and a small number of commercial service providers 
and commercial organisations are actively involved in phase 
Le, 


- In order to stimulate the creation of an economically viable 
market place for X.400(1988) products (i.e., MTAs, UAs, etc.) 
(i.e., users are willing to purchase such products), it is 
recommended that a suitable minimum number of new software 
implementations and or modifications to existing software 
implementations be funded. The resulting software to be 
inserted into the Public Domain free of any financial 
restrictions on further commercial exploitation. By using 
this mechanism, Small and Medium Size Enterprises (SMEs) will 
be encouraged to commercially exploit such products. 


- Due to the strong influence of the R&D community within the 
pilot plus the desire to produce standardised products 
quickly and pragmatically, it is recommended that any 
standards proposed within the scope of an X.400(1988) pilot 
(for example standards re: character sets and body parts 
gatewayed to and from X.400(1988) and RFC 822 / MIME) are 
conformant to and candidates for Internet standardisation. As 
a concrete example of the standardisation process, this means 
that at least two independent software implementations, for 
each product category, (of which one product preferably in 
the Public Domain) must be proven as interworking to a 
proposed standard before the proposed standard can be 
elevated to draft standard [20]. 
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- To ensure that there is a market driven demand for 
X.400(1988) products within the commercial market place, it 
is recommended that the maximum number of Public Domain 
implementations that are funded, by any one public funding 
organisation, is two. It is desirable that at least one other 
product, preferably commercially based and not within the 
Public Domain, is produced. 


- In order that any necessary information required for the 
effective operation of the X.400(1988) pilot, including not 
least OID assignments, mapping rules, information about 
interconnection partners, naming authority information be 
made widely available, it is recommended that an 
electronically accessible information base be established. 


- In order that any necessary organisational issues needed for 
a deployment of an X.400(1988) service have a body in place 
to deal with this issue, it is recommended that the pilot 
either identify and list which bodies are responsible for 
which issues or else actively ensure that a suitable body is 
being put in place. 


Appendix B - A number of detailed guidelines. 
The Task Force has the following detailed guidelines: 
*Product and operational service guidelines* 


- To ensure that there is no degradation of X.400 (1988) 
service between X.400(1988) originators and destinations, the 
topology of the MTS must be such that no X.400(1984) MTA acts 
as a relay between any two X.400(1988) users. 


- As the existing R&D X.400(1984) service (formerly COSINE 
MHS) now comprises a large number of X.400(1988) capable 
RELAYs, it would be relatively straight forward that the 
existing COSINE MHS RELAYs be one of the first communities 
that are migrated to X.400(1988) capabilities. This would 
ensure that X.400(1988) MTAs using the RELAY backbone 
experience no loss of service. 


- To be able to operate an X.400(1988) service a properly 
operated X.400(1988) infrastructure should be established, 
consisting of X.400(1988) MTAs, X.400(1988) MTAs with 
downgrading capabilities according to RTR 3, Message Store 
services and gateways to RFC 822 based upon RTR 2 and 
extended gatewaying functionality for multimedia mail. 
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- To ensure maximum use of the OSI supporting layers plus 
support of normal mode RTS, it is recommended that a 
migration to ISO 10021 is effected i.e., straight to use of 
the full OSI stack with normal mode RTS. 


-— To ensure maximum quality of service as impacted by 
implementation decisions related to the ’General Extension 
Mechanism’, it is recommended that no minimal X.400(1988) 
MTAs, which relay the syntax but understand none of the 
semantics of extensions, should be used. 


- It is recommended that all X.400(1988) MTAs should generate 
reports containing extensions copied from the subject message 
and route reports through the DL expansion hierarchy where 
appropriate. 


- It is recommended that all X.400(1984) UAs are able to 
generate and display DDAs. This will allow such systems to 
address X.400(1988) Common Name Attribute users. 


- To enhance connectivity to both X.400(1984 and 1988) 
management domains without degradation of X.400 (1988) 
service, management domain entry points that support both 
X.400(1984 and 1988) are recommended. 


- To ensure total connectivity between RFC 822 domains 
migrating to X.400(1988), it is recommended that a local 
X.400-to-RFC-822 gateway is made operational or a reliable 
service agreement for the external provision of such a 
gateway is effected before any migration begins. 


*Migration utilities needed* 


- It is considered very helpful if conversion utilities that 
allow a flawless conversion of an RFC 822 user’s existing 
mail folders to a X.400(1988) product’s folder system be 
implemented. However further investigation is needed before 
recommending that such tools be made a mandatory part of any 
funded software development. 


- It is recommended that the ease of configuration of 
X.400(1988) products is made as automatic as possible. 
Consideration should be given to a) modern user interfaces b) 
automatic processing of ’old RFC 822’ configuration files 
into the ‘new X.400(1988)’ configuration files i.e., a reuse 
of the user’s previous options and configurations should be 
the result. If a ’simple’ configuration interface is needed 
it should be as compatible as possible with the present RFC 
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822 mailer’s i.e., this concretely means editing of ASCII 
files. 
*Issues for further study* 
The pilot X.400(1988) messaging service must ensure that the issues 
listed below are either being investigated by an appropriate body or 
if not initiate actions to properly address them. The issues have 
been grouped under Products, Organisational and Deployment. 


— Products 


- Any X.500 DSAs, DUAs, APIs e.g., LDAP, etc. changes 
needed to support X.400(1988) messaging. 


- X.400(1988) MTAs, UAs, MSs, gateways to RFC 822/MIME 
and X.400(1984) plus gateways to other messaging 
systems e.g., Microsoft Mail, Lotus cc:Mail, etc. 

- User Interfaces that integrate X.400(1988) UAs and 
X.500 DUAs with user applications such as Word 


Processors, etc. 


- E-mail network management software both for users and 
administrators 


- Organisational 
- trusted network for security (i.e., the distribution of 
security keys) and whether this trusted network should 
or can be the same as the PEM trusted network presently 
under deployment. 
—- usage of PEM within X.400 (1988). 
-— PEM to and from X.400(1988) gatewaying. 


- how to register and publicise object IDs for 
X.400 (1988). 


- addresses are well publicised of PRMD and ADMD 
registration authorities. 


- creation and modification authority for X.400-to-RFC- 
822 mapping rules is defined. 


- creation and modification authority for MTA routing 
rules is defined. 
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- what methods should be used to liaison to other bodies 
like IETF, ISO, EEMA, EMA, etc. 


- ensuring that any Public Domain software needed for the 
X.400(1988) service is distributed widely, quickly and 
efficiently. 


—- Deployment 


- which services should start such a migration (i.e., 
COSINE MHS RELAYs, Universities, other). 


- the topology of the X.400(1988) MTS. 


- addressing of users between X.400(1984 and 1988) and 
RFC 822 e.g., how will X.400(1988) T.61 address 
components be processed by X.400(1984) and RFC 822 
systems. 


- which X.400(1988) body parts MUST be supported by the 
research community. 


- if any new APIs - or modified APIs - are needed for 
X.400(1988) and messaging in general. 


- the specifications and development of any needed Public 
Domain software. 


- what existing Public Domain software should be modified 
to accommodate X.400(1988) systems. 


- how rapidly to deploy the X.400(1988) service. 

- ensuring that there is ’little or no loss of service’ 
in any migration from X.400(1984), or RFC 822, to 
X.400 (1988). 

- considering what Value Added Services, based upon 


X.400(1988), could be started to encourage uptake of 
X.400 (1988). 
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